Bank Demo 3, or BD3 as the files and mainline procedure are named, is ademonstration program which illustrates how Ada and its tasking mechanism can beused to create a model of an activity in the real world. BD3 is a model of abank, where the bank contains several tellers, implemented as Ada tasks, and isused by customers, also implemented as Ada tasks. The user at the console canmonitor the status of the bank and the accounts of its customers and cause morecustomer tasks to execute, thereby increasing the level of activity at the bank.The tasks all operate in parallel, so a variety of events can be thought of ashappening at the same time, controlled by the Ada runtime system which is builtinto the Ada program by the Ada compilation system.
This document and the associated software are presented as an introductionto the Ada language and its tasking capabilities. While the author attempted tomake this document as easy to follow as possible, a limited knowledge of Ada isassumed. Variable assignments, type definitions, and procedure and packagespecifications are presented in correct Ada syntax without much explanation. Ifthis proves to be a problem, the ADA-TUTR shareware program will help a lot inbringing the user up to date with an understanding of Ada syntax. Regardless,the program in the file BD3.EXE can be run without any knowledge of Ada at all,and the tasking demonstration can be observed.
SET page=1
BEGIN HEADER
BD3 - A Demonstration of Tasking in Ada
END HEADER
BANK DEMO 3
A Demonstration of Tasking in Ada
by Richard Conn
RESERVE 4
SECTION Introduction
BD3 is a model of a bank. The Ada package called BANK represents the bankitself, and the bank contains four tellers, represented by an array, namedTELLER, of four tasks. BD3 is written in an object-oriented fashion in the Adaprogramming language.
Each task, TELLER(1) to TELLER(4), supports one entry point, calledREQUEST, which is used by tasks outside the BANK package to communicate with aTELLER(n) task and request a transaction. Four transaction requests arerecognized by a TELLER(n) task, as shown in Figure TRANSACTION.
Each TELLER(n) task performs one of these four transactions at a time. Anexternal task calls (makes a rendezvous with, in Ada terminology) a TELLER(n)task through its REQUEST entry point, passing one of these transaction names asa parameter, and the TELLER(n) task processes the request. For example, a codesegment in an external task may look something like Figure CALLTELLER. Thiscode segment was extracted from the body of the CUSTOMER task definition in thepackage CUSTOMER_WORLD (see later).
This demonstration program also contains several other tasks, calledcustomer tasks. These tasks, hidden inside the package CUSTOMER_WORLD, operateindependently and interact with the various teller tasks. The customer tasksmake requests to the teller tasks, asking to be added as a customer of the bank,making deposits, and making withdrawals. Using the Ada inter-task rendezvousmechanism to communicate, if the teller task is already servicing anothercustomer task, the customer task "waits in line" (having been placed in theimplicit queue associated with the teller's entry point). If queued, thecustomer task is serviced after the tasks in the teller's queue in front of himhave been serviced. Indeed, the model is similar to the real world.
From the mainline procedure, the user can monitor the bank and itsactivity. He can obtain a status report from the bank (which includes thebalanace of each customer, the number of transactions requested by eachcustomer, and the number of transactions processed by each teller), cause newcustomer tasks to start up, and shut down the system and exit the program. Forthose Ada compilers which do not allow tasking to proceed while the current taskis waiting for input (such as many of the Ada compilers available for the IBMPC), a continuous display function is also provided to the user which displaysthe bank's status, delays five seconds (allowing the various tasks to run), anddisplays the bank's status again. This command option displays ten statusreports before returning the user to his prompt.
RESERVE 4
SECTION Execution of the Program
Figures EX1 to EX7 show various displays during the execution of theprogram. These displays were generated on a SUN workstation, where the programwas compiled by the Verdix Ada compiler. These displays may be different fromwhat you see if you compile the program on an IBM PC, particularly in thatVerdix Ada does not suspend all tasks while the current task is waiting forinput from the console. While we are at the prompt in these figures, all tasksare running in parallel with our input activity. On some compilers this willnot be the case, and the parallel operation of the tasks will not be seen untilthe user issues the 'c' (continuous bank status) command.